The need for both voice telephony services as well as data services is common. Traditionally, voice communications or voice telephony was provided over traditional circuit-dedicated or circuit-switched telecommunications networks, which are bandwidth inefficient when compared to data or packet networks (hereinafter “packet networks”). For a variety of reasons, including reduced overall costs, increased efficiency, and the popularity of the Internet and other packet networks, the demand for exchanging real-time or near real-time information, such as voice and video, over such packet networks has dramatically increased.
Unfortunately, the increased demand for the use of packet networks to exchange real-time information has resulted in increased congestion of such packet networks. Congestion of packet networks is further complicated by the need to provide different levels or classes of services for the exchange of voice and video over packet networks. The different levels or classes of services may include, for example, Quality of Service (“QoS”) guarantees, reserved bandwidth or data rates, and guaranteed error and/or delay levels. Unfortunately, since not all packet network technology was originally designed to support the real-time exchange of voice and/or video information, the capability to implement the different levels or classes of services, while also providing a solution to the congestion problem mentioned above, is considerably challenging.
Packet networks are made up of data or packet switches, such as, for example, Asynchronous Transfer Mode (“ATM”), MultiProtocol Label Switching (“MPLS”), Frame Relay, X.25, Ethernet, and Internet Protocol (“IP”) switches. Packet networks have data packets, cells, frames or blocks (hereinafter “packets” or “cells”) that are either of fixed length or variable length. In general, packet networks were originally designed to exchange non-real time data and to operate on a best-effort delivery basis such that all traffic has equal priority and an equal chance of being delivered in a timely manner, in contrast with the needs of voice or video communications. Some of the packet-switched technologies that may be used for voice communications include, without limitation, Voice Telephony over ATM (“VToA”), Voice over Frame-Relay (“VoFR”), Voice over Digital Subscriber Line (“VoDSL”), and Voice over IP (“VoIP”).
A packet network or packet switch is considered to be in a congested state when the total bandwidth of the packets entering the output queues of a packet switch at an egress port becomes greater than the bandwidth available at the egress port. Congestion management within packet switches has traditionally focused on two software approaches, each with their own advantages and disadvantages. The first approach involves the implementation of a priority scheme used by a scheduler and may be referred to as the “strict scheduler” approach. The second approach involves the enforcement of policy decisions that stop certain packets from entering an output queue (hereinafter “queue”) if the queue gets to a certain fill level. This approach may be referred to as the weighted fair queuing (“WFQ”) scheduler approach. The distinction between these two common congestion management approaches concerns the manner in which the scheduler arbitrates between the different queues.
The strict scheduler approach involves performing a strict prioritization on the different queues. For a given time where bandwidth is available to the egress port, the scheduler in such an approach simply checks the highest priority queue first. If there is a packet in the highest priority queue, then, it is sent to the egress port, otherwise the scheduler looks to the next highest queue for a packet to send to the egress port. This cycle is repeated through all the queues until the scheduler finds a packet to send. Once a packet is sent, the cycle is repeated, again starting with the highest queue on down. This works well for the higher QoS traffic since they are given absolute priority over the lower QoS queues. Thus, the delay or delay variation for the transmission of the packets will be low for such high priority traffic, which is necessary for real time services and applications such as voice and video.
The problem with the strict scheduler approach is that the lower QoS traffic can be choked out at the expense of higher QoS traffic that, in some situation, could be dropped due to other policy decisions. For example, in the case of ATM traffic, non-conformant rt-VBR (CLP=1—not guaranteed by network) traffic would have priority over the lower service category conformant nrt-VBR (CLP=0—guaranteed by the network) traffic. This problem can be particularly limiting to the service provider. The service provider is forced to use lower oversubscription rates, which results in a lower network efficiency, lost revenue, and a lower return on investment.
The WFQ scheduler approach utilizes a weighted fair queuing scheduler between the various queues of an egress port of a packet switch. The WFQ scheduler determines how much bandwidth should be reserved for each QoS traffic by the weight that is associated with the connections or traffic belonging to each particular QoS queue. For example, if the weight of the highest QoS queue is such that it requires 5% of the link or egress port bandwidth, then the queue is guaranteed 5% of such bandwidth. Each queue is now isolated from the other queues in that each queue is given a certain percentage of the link or egress port bandwidth. Further, if one of the queues begins to back up because of congestion, then a policy based discard threshold may be enabled to drop packets according to the chosen policy for that QoS queue. This function is also isolated from the other queues.
The problem with the WFQ scheduler approach is that the delay and delay variation for real time services (assumed to be higher QoS queues) have been increased. This is a result of the higher priority queues not having full access to the link bandwidth before the other queues. For example, if a lower priority queue was weighted such that it required 90% of the link or egress port bandwidth, then packets in a higher priority queue may be delayed given the lower priority queue's 90% link or egress port bandwidth. Also, as with the strict scheduler approach, policy based decisions between the queues are not utilized. Additionally, the isolation and independence of the different queues forces any oversubscription to be performed individually for each queue or QoS traffic type, resulting in less allowable total oversubscription for a given link.
Another congestion management approach, which will not be discussed in detail herein, involves a packet switch to packet switch congestion management technique that includes a first packet switch communicating to a downstream second packet switch that it is becoming congested and requesting the second packet switch to reduce its data rate for a particular queue or QoS traffic so that the first packet switch can recover from the congestion.